Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9701/000025_owner-urn-ietf _Thu Jan 30 13:41:22 1997.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA06625 for urn-ietf-out; Thu, 30 Jan 1997 13:41:22 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA06613 for <[e-mail]>; Thu, 30 Jan 1997 13:41:11 -0500
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA15531  (mail destined for [e-mail]); Thu, 30 Jan 97 13:41:08 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA05878; Thu, 30 Jan 1997 12:40:21 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA27743; Thu, 30 Jan 1997 12:40:38 -0600 (CST)
Date: Thu, 30 Jan 1997 12:40:38 -0600 (CST)
Message-Id: <[e-mail]>
To: Keith Moore <[e-mail]>
Cc: Tim Berners-Lee <[e-mail]>, Daniel LaLiberte <[e-mail]>,
        "Martin J. Duerst" <[e-mail]>,
        "Ron Daniel Jr." <[e-mail]>,
        URL mailing list <[e-mail]>, [e-mail],
        [e-mail]
Subject: [URN] Re: Relative URLs and URNs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Keith Moore writes:
 > > Keith, you make a good point that relative URIs are limited in
 > > persistence to the persistence of the two URIs.
 >
 > I don't know which two URIs you're talking about.

The two URIs are something like an http URL and a URN of some kind.  A
relative URI could be relative to either kind of absolute URI.  Of
course, if the scheme of an absolute URI does not support relative
URIs, the URI could not be used as the base URI of a document.

 > The persistence problem, as I see it, comes from wiring
 > non-persistent information into the URI -- in this case, the
 > grouping of subsets of URI space -- and depending on that
 > information to be persistent.

Relative URIs may or may not wire non-persistent information depending
on how your resolution service works.  The grouping of subsets of a
URI space is a grouping of the *identifiers*, but that does not
necessarily mean that the *resources themselves* are similarly
grouped.  A redirection can be returned by the resolution service for
any part of the group pointing the client off to where the resource
currently lives (or closer to it anyway).  In fact, a hierarchical
subdivision of the group can make it even easier for the resolution
service to provide that redirection, and more importantly, for the
client to (more scalably) remember the redirection for a whole
subdivision.  All this and a bit more is supported by the path
scheme resolution mechanism.

Keith, you seem to be arguing not only against relative URNs but
against any hierarchical structuring of the URN space.  The two issues
are closely related since once you have hierarchical structuring, you
can also easily have relative identifiers.

What is the difference between always using absolute URNs such as

  urn://path/A/B/C/D.doc
  urn://path/A/B/C/E.doc

and using relative URNs such as

  C/D.doc
  C/E.doc

within a document having a base URN of

  urn://path/A/B/index.doc

It might be the case that for some resolution mechanisms, you resolve
the relative part by itself in a different way than you resolve the
corresponding absolute URI.  So you might not be able to resolve
urn://path/A/B/C/D.doc directly but instead, after resolving
urn://path/A/B/, you find out about some different kind of service (say
an HTTP server) that you request C/D.doc from.

 > Tim B.L. said:
 > > But Dan La L was right too in pointing out that the relative URI
 > > may in fact be longer lived than the absolute. So it is not a
 > > clear case.
 >
 > Unless I misunderstood his argument, it seemed to be predicated on
 > the idea that old name spaces will go away and need to be changed.
 > But since the URN framework is specifically designed so that old name
 > spaces do not need to be changed, I don't accept the premise.

The old name space may live forever with no problem - we only have to
guarantee that the names are never used again - no problem (even for
human-meaningful names).  The real problem is in finding a resolution
service that will resolve the old names.  Say a name space is created
in such a way that it is really difficult to actually resolve
identifiers in a scalable way.  One way to solve this problem is to
create a new name space with better resolution mechanisms.  The
relative URIs in the documents could remain unchanged if both the old
and new name spaces supported relative URIs.

(Footnote: Another different kind of problem for finding a resolution
service could occur if hardly anyone cares about the resources any
more, no matter how scalable the resolution service might be.  The
problem might be to find a cheap enough resolution service.)

(Footnote: Finding (looking up) a resolution service is an essential
part of the resolution process.  You have to have a specific place
(location/address) to start the lookup process.  That's what makes a
name logically the same as an address, but we are not allowed to talk
about that on the URN list - email me replies on that.)

 > As far as I can tell, if we're going to have persistent relative URNs
 > (or equivalently, URNs that reference portions of a single resource)
 > we're going to need a level of indirection for relative URNs just like
 > we have for normal URNs.

Yes, and providing that indirection is no more of a problem for
relative URNs than for absolute URNs, depending on how your resolution
service works.

If you are thinking only of resolution services that work with flat
name spaces, then indeed relative URNs will be a problem.  Obviously,
document writers will not be able to use URNs in non-hierarchical name
spaces as base URIs.

 > That is,
 >
 > given a resource a1 with URN "A1" and a similar resource a2 with URN "A2",
 > (for some meaning of "similar"), it's not reasonable to assume that
 > the portion of a1 named by "A1/foo" is similar to the portion of
 > a2 named by "A2/foo".

Correct. It would be an error to assume that.  Relative URNs can not
be directly compared for equivalence without prepending the context of
the base URN that makes them absolute.  If you know that A1 and A2
are alternative (equivalent) URNs for the same resource, then you *do*
know that "A1/foo" is equivalent to "A2/foo", otherwise you do not
know they are equivalent.

The same is true of absolute and relative URLs, by the way.

 > My view is that since persistence is an important property of URNs,
 > we should not define relative URNs (or URNs that specify portions of
 > documents) until we understand how to define them without diluting
 > the persistence of URNs.

Relative URNs do not dilute the persistence of URNs any more than
hierarchically structured URNs are non-persistent.

 > If we disallow unencoded '/' within URNs for now, we can always add
 > relative URNs later when we understand them better.

True, but you would also be disallowing hierarchical name spaces such
as the path scheme defines.  Understanding relative URNs is a good
idea, but I don't understand why it is so difficult to understand
them.

Earlier, regarding locations within a resource, you said,

 > Even then, I'm not sure what it means to talk about references
 > relative to a "Base URN" ...because this assumes that the "Base URN"
 > will need to change while the intra-resource reference names
 > need to stay the same.

Important difference: The base URN *may* change (e.g. to a newer
better name space), while the intra-resource (or inter-resource - same
can of worms) relative identifiers *need not* change.

All this talk of hierarchy should be extended to also include Tim's
matrix space with relative URIs of the form ";name=value;name=value".
John Mallery has suggested a URN scheme that is entirely matrix based.
John, it might be useful for you to briefly describe it now.
I need to give it more thought myself, to figure out how to make
the resolution scalable.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/